…side

/api/upload uses the service-role Supabase client (bypasses storage RLS),
which src/lib/supabaseAdmin.ts's own doc comment says callers must gate with
their own authorization/limits before running. This route had none: no file
size cap, no content-type allowlist (the client-reported file.type was
trusted directly as contentType), and the storage path came straight from
the request body instead of being generated server-side.

Anonymous submission is intentional here (visitors upload a logo/screenshot
while submitting a new listing, see src/views/Submit.tsx), so this doesn't
add auth — but it does close off:
- unbounded storage/egress cost from arbitrarily large or numerous uploads
  (now capped at 5MB per file)
- uploading non-image content under an attacker-chosen content-type
  (now allowlisted to png/jpeg/webp/gif/svg)
- a caller picking their own storage key, which could collide with another
  upload's path (upsert: false would then reject the legitimate one) or be
  used to write outside the flat filename pattern the frontend generates
  (path is now always server-derived: timestamp + randomUUID + extension)